Report  Documentation  Page 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 

1 .  REPORT  DATE  2.  REPORT  TYPE 

27  OCT  2014  N/A 

3.  DATES  COVERED 

4.  TITLE  AND  SUBTITLE 

Value-Driven  Incremental  Development 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

Ozkaya  /Ipek 

5d.  PROIECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Software  Engineering  Institute  Carnegie  Mellon  University  Pittsburgh, 

PA  15213 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR'S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release,  distribution  unlimited. 

13.  SUPPLEMENTARY  NOTES 

The  original  document  contains  color  images. 

14.  ABSTRACT 

15.  SUBIECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF:  17.  LIMITATION  OF 

18.  NUMBER  19a.  NAME  OF 

a.  REPORT  b.  ABSTRACT  c.  THIS  PAGE  S  AR 

unclassified  unclassified  unclassified 

l 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


Value-Driven  Incremental  Development 

Integrating  Architecture  Analysis  and  Assurance  With  Development 


Objective 

Investigate  how  quality  attribute  requirement  allocation 
and  dependency  analysis  inform  incremental  development  and 
assurance  through  managing  rework  during  development. 
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Multi-dimensional  Analysis 

What  is  the  design  implication  of  a  release  decision? 
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Architecting  for  Incremental  Assurance 

What  are  the  assurance  implications  of  a  release  decision? 
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Embedded  Hardware  Target 


Quality  Attribute  Allocation 

How  do  we  break  architectural  features  into  increments;  what 
measures  are  needed  to  make  good  release  decisions? 


Value  measures 


Solution  Approach 

•  Collect  quality  attribute  requirements  using  architecture-tactics 
questionnaires 

•  Create  models  for  deployment  view  augmented  with  partitioning 
and  fault-tolerance  information 

•  Generate  an  experiment  environment  where  models  can  be 
seamlessly  exchanged 

•  Apply  modifiability  and  fault-propagation  metrics 

•  Validate  that  augmenting  with  fault-tolerance  information 
provides  information  about  propagating  rework 

•  Validate  whether  incremental-assurance  information  can  be 
contained  within  architecture  changes 
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Multi-Dimensional  Analysis  Drives 
Increment  Value  Assessment 


Selected  FY14  Results 

•  Improved  rework  analysis  by  making  architectural  dependency 
information  (e.g.,  fault-propagation  dependencies)  available 

to  developers  during  architecture  modeling  and  development 

•  Eliminative  argumentation  defined  as  a  core  concept  that 

is  a  basis  for  arguing  confidence  and  in  establishing  the  theory 
of  confidence 

•  Incremental  evolution  of  quality  attribute  requirement 
allocation  using  architecture  tactics-based  data  collection 
occurs  through  small  refinements  and  ratcheting  of  response 
measures.  Empirical  studies  and  surveys  with  organizations 
revealed  architectural  rework  occurs  in  such  context  and 
can  be  managed  by  better  quantification  of  technical  debt. 
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Multi-view  analysis  allows  developers  to  see  different  types  of 
dependencies  that  need  to  be  investigated  when  changes  occur 
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